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Abstract 

The continuing evolution of the rotarv wing indus- 
try demands increasing analytical capabilities. To 
keep up with this demand, software must b' 
structured to accommodate change. The approach 
discussed in this ^aper for meeting this demand is 
to M restructure" an exist* «g analysis. The motiva- 
tional factors, basic principles, application tech- 
niques, and practical lessons from experience with 
this restructuring effort are reviewed. 

Introduction 

As the rotary wing industry matures it is getting 
increasingly difficult to extract the next significant 
technological advene* . Improved understanding of 
the physical phenomena of rotary wing aircraft 
requires more complete analytical representations. 
Advances in computer technology are allowing 
larger more sophisticated analyses than were 
previously practical. As a result, »;•«* demand for 
complex analysis capability is i,ro- -apidly, 
with increasing emphasis - v ; . plinary 
analysis. The changing and ,~r. <ir *nds of 
rotary wing analysis necessitate oftware be 

structured to quickly and efficiently accommodate 
change if it is to take advantage of continuing 
developments in this dynamic environment. 

Software may be designed with structure emphasiz- 
ing muinta’nabllity and modifiability. Software 
structured toward this goal provides reduced 
modification and maintenance costs, reduced time 
delay for adding new capabilities and improved 
reliability through a reduction in the number of 
undetected errors. This may be accomplished 
through judicious partitioning of softv are into 
functional modules, provision of well-defined paths 
of data flow, and adherence to a control 
hierarchy. 

The proposed approach try obtaining a well struc- 
tured rotor loads program is to "restructure" an 
existing analysis. Restructuring can bo a t.,ne- 
saving and cost-saving alternative to developing 
new structured software. It consists essentially of 
reorganizing the code of an existing analysis to fit 
a structured design, while maintaining the theo- 
retical basis for the analysis. 
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A Boeing Vertol rotor analysis program (C-60) is 
currently being restructured. Large complex 
blocks of multi-functional code are ceing broken 
down and reorganized into succinct functional 
modules. Related pieces of code, previously 
scattered throughout the program, are being 
gathered to form functioi al modules. Standardized 
formats for variable definitions, input d:*a, output 
data, and documentation are being implemented. 
Even though the restructuring process is not yet 
complete, code performing a given task is now 
easier to find, understand, isolate, and modify. 
Variables, input data, and output data are also 
now easier to identify, understand, and modify ~s 
needed. The o veraf’ result is that new capabilities 
may be implemented in less time, *t lower cost, 
and with improved reliability. 

Background 

novation for More Capable Analyses 

Physical understanding is expanding rapidly in 
areas related to analytical modeling of nonuniform 
down wash, ^otor/fuselage coupling, vibration, 
noise prediction, rotor airloading, and composite 
material behavior, among others. There is a 
corresponding demand for improved analytical 
capability to reflect these advances More sophis- 
ticated designs, such as JVX and LHX, and ex- 
panded flight envelopes push many analyses 
beyond their present bounds of application, into 
regions where simplifying assumption^ such as 
small angles, linearity, and low coupling break- 
down. 

Compounding these demands for expanded analyti- 
cal capabilities is the pressing need for more 
accurate analytical predictions to facilitate finely 
tuned multi-variable design benefit trade-off 
studies. Many of the straight-forward one or two 
dimensional design problems have been solved. 
The largest potential rotorcraft improvements 
require complex trade-offs involving different 
technologies having a consistent level of complexi- 
ty. As incremental isciated technology design 
benefits become smaller, the need for more com- 
plete, complex inter-disciplinary models increases. 
This view is supported by Kerr, Potthast, and 
Anderson'. Eventually, the requirements of more 
demanding interdisciplinary tradeoffs will increase 
to the point where specialized analyses in isolated 
disciplines w!M become inadequate and possibly 
even misleading. 


171 


precuxnb bats blank mot nuao 



w 









n 

■f* 

-4 


& 






Advances in computer technology and software 
development add fuel to the movement for mo**e 
capable analyses. These advances provide ex- 
panded resources and/or reduced cost in terms of 
CPU time, memory usage, and I/O (input/output) 
capacity and sophistication. Approaches which 
we^e previously beyond practical resource limita- 
tions are now viable current or near-future op- 
tions. Current computer systems now allow pro- 
gram structure to be independent of memory 
constraints, in contrast to the memory overlay 
structure restrictions of the past. Increasing 
sophistication of computer tools (such as shown in 
Table I) air' motivate more capable analyses. 

Practical Limitations of Current Programs 

The development of more capable analyses is easier 
said than done. There is a history of difficulties 
with the development and upgradino of complex, 
multi-disciplinary analyses, and the prospect of 
developing even more sophisticated programs with 
the requirement for continuous updating, projects 
an image of long development time, high costs and 
questionable results. 

The primary factor contributing to th<_ difficulty of 
analysis development today is the tendtncy of 
large multi-user multi-analyst programs to n/o've 
and grow in complexity beyond the comprehei sion 
of any single user/developer. It is as if such 
analyses follow a specialized law of entropy, teno- 
ing toward ever increasing disorder until reaching 
“saturation of comprehensibility". Program mainte- 
nance and modification become increasingly difficult 
as clarity and understanding are gradually re- 
plac'd by obscurity and misunderstanding. 
Beryland 2 presents two observations w >cn summa- 
rize this behavior of large programs .• "The Law 
of Continuing Change" ard "The L : of Un- 
structuredness" as show', in Figure 1, 

Eventually, at least one toe »iy irreversible or 
untraceable revisions is made. Correlation and 
reliability falter suddenly. Previous analytical 
predictions car no longer be reproduced. Things 
that "worked" now mysteriously fail and the analy- 
sis "dies" suddenly. If a reliable backup version 
exists the analysis may enjoy a temporary reprieve 
but eventually it is iikei / to follow the path to 
extinction. Therefore, the program with chronic 
"saturation of comprehensibility" will eventually 
reach the point at which no further cost-effective 
growth is possible because revisions can no longer 
be fully understood or drugged. 

The tendency toward disorder causes serious 
* roblems long before the analysis actually reaches 
complete "saturatic ^ of comprehensibility", that is, 
the point at wnich revisions can no longer be 
made. Complexity grows with each expansion of 
capability, as change is added to change without 
an overall plan or global structure. The analysis 
evolves gradually via the work of a variety of 
programmers, analysts, and engineers, with a 
corresponding variety of individual styles and 
preferences, (sev ’’“able 2). Complexity and 
apparen* disorder result as the natural subtle 
accumulation of the effects of melding individual 


styles. These trends are compounded by a lack of 
adequate, accurate, current documentation and the 
growing innate complexity of the analysis due to 
expanding requirements. Excessive complexity 
reveals itself in highly unpredictable and often 
excessive person-hour costs for program main- 
tenance and modification, and time delays tor new 
capabilities. 

As analytical capability is expanded, additions are 
made to program input and output. Additions for 
expansions of capability are often made quickly 
and without thorough coordination. Additions to 
input and output are often made more expediently 
than analytical revisions, and are sometimes left in 
"temporary version" form. The result is input and 
output which are not clearly defined, are possibly 
redundant, are not well organized, and are prone 
to error. This situation results in the expense of 
extra user-hours for preparation of program input 
and : iterpretation (sometimes deciphering) of 
prog* am output, and an increased probability of 
undetected input error and/or output misinter- 
pretation. 

Other symptoms of saturation of comprehensibility 
are less obvious, but have the same root cause. 
For example, poor correlation may be an indication 
of undetected errors within the analysis, un- 
detected misuse (such as input error), or un- 
detected misinterpretation of analysis output. 
Compromised reliability is another w. rning sign of 
excessive comolexity. An analysis which behaves 
very wel; sometimes and very badly other times is 
providing a warning. Growth of analytical com- 
plexity is often accompanied by increased depen- 
dence upon the specialized experience of experts 
associated with specific analyses (described by 
Kerr, Potthast, and Anderson 1 as "Sam’s Program 
Syndrome"). This development implies poor or 
nonexistent documentation and very complex code, 
so that others are unable to understand the 
analysis. 

A Solution: Structured Program Design 

The solution to this problem is the development of 
analysis programs which will start out and remain 
clear and understandable throughout a long life- 
cycle of maintenance and modification. This may 

be achieved by using "Structured Program Design" 
techniques to design software for maximum main- 
tainability and modifiability. 

Structu. ad program design is a formal methodology 
for software design which was developed in an 
attempt to deal w»th the rapid expansion of soft- 
ware associated costs which began in the 1970‘s. 
Bergland 2 provides some historical perspective in 
"A Guided Tour of Program Design Methoaologies" 
in which the author outlir^s general trends in 
software development from "Cottage Industry 
Programming" of the 1950‘s through "Heavy Indus- 
try Programming" nf the lOSO's to the birth of 
" Structured Programming" i.i the 1970's. At one 
point, over one percent of the GNP (gross national 
product) was being spent on software 2 . This 
stimulated early attempts at formulation of design 
criteria and programming techniques. 
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Today, a great deal of effort is being expended in 
attempts to formalize and standardize software 
design procedures to yield more maintainable, 
modifiable, and user-friendly programs. Struc- 
tured program design is being applied in the 
rotorcraft field, including a government develop- 
ment program named 2GCHAS (Second Generation 
Comprehensive Helicopter Analysis System). 
Documentation has become a large part of most 
program development efforts. Efforts are being 
made to standardize, streamline a * nearly auto- 
mate the generation of both code and documenta- 
tion. Some examples of this are specification of 
FORTRAN coding standards 3 , development of a 
"generic" architecture 4 , development of programs 
which generate diagrams directly from code 5 , and 
the proposal of formal program design procedures 
such as data flow design or programming cal- 
culus 2 . 

An Approach to Structured Program Design 
Development Strategy 

Structured program design is a general term 
referring to an application-dependent design 
procedure. It may be defined as "design for the 
best solution". The key to this approach is a well 
chosen definition of "best"; one that is well 
matched to the specific application. The pro- 
cedure begins with the selection of a general 
goal, followed by a trade-off of benefits to 
prioritize different design criteria. A variety 
of terms have been defined to serve as design 
criteria. Terminoiogy varies, as illustrated by the 
list of terms provided as tables 3 and 4, but 
similar concepts are defines in references 1, 2, 4, 
and 6. Design criteria used in the present study 
are efficiency, generality, maintainability, .mod- 
ifiability, reliability, & utility as defined in table 5. 

The general goal (or measure of goodness) chosen 
for the software design discussed here is mini- 
mum total lifecycle cost. This lifecycle includes 
development, checkout, release, operation/ 
maintenance/modification, and maturity, as shown 
in Figure 2. Yourdon and Constantine 6 describe 
the ideal program as "cheap to develop, che«.D to 
operate, cheap to maintain, and cheap to modify". 
The relative cost and importance of the different 
phases of a program's lifecycle vary from appli- 
cation to application. The resulting prioritization 
of design criteria should vary accordingly. For 
example, the strategy for development of a payroll 
program might differ dramatically from that for a 
technical analysis in a volatile field because of 
different prioritizations for different aspects of the 
program lifecycle (i.e., efficiency for operating 
costs versus modifiability for modification costs). 
As another example, execution time and reliability 
might be most important for a real-time simulation. 
In each case, the goal of minimization of total 
lifecycle cost is reflected in tfv* application-specific 
prioritization of criteria. 

For our design, maintainability and modifiabil ; ty 
were chosen as the most important design criteria. 
This prioritization results from heavy weighting 
applied to person-hour requirements *or expansion 


of analytical capability and very-long-term ac- 
cumulation of maintenance costs. In addition, 
coincident improvements in utility (i.e.: 
user-friendliness) and computational efficiency 
are anticipated from restructuring of input and 
output functions and elimination of redundant 
and repetitious calculations. However, improve- 
ments in these attributes are to be achieved only 
at no expense to maintainability and modifi- 
ability. 

Two options exist for development of wall struc- 
tured analyses. These are (1) build a new analy- 
sis from "scratch", or (2) restructure an existing 
production analysis. Restructuring is reorganiza- 
tion of an already debugged, validated, correlated, 
"mature" analysis. It is the imposition of struc- 
ture on an existing analysis. This approach 
utilizes current analysis theory, including deriva- 
tion of equations, and solution method, and keeps 
current correlation intact. It utilizes informaticn 
from current documentation in the new documenta- 
tion. Checkout or validation consists of comparing 
results of the current poorly structured analysis 
with the new restructured analysis and implicitly 
takes advantage of all prior validation and correla- 
tion efforts. While restructuring does not, in 
general, include provision of any new capability it 
may be coincident with provision of new capability. 
An additional benefit is that the program remains 
operational and useful throughout the restructur- 
ing process, thereby providing immediate gains. 
In contrast, development of a new structured 
analysis from scratch begins with approach deve! 
opment and derivation of equations and thus may 
include new capability. However, starting from 
scratch does not utilize results of prior correla- 
tion, documentation, etc., and the program does 
not become useful until the long validation/ 
correlation effort is complete. 

Restructuring is the preferred approach if a 
"mature" analysis is available which is minimally 
organized and has been validated and correlated. 
The most difficult, costly, and time-consuming 
tasks to perform before a large program becomes 
useful are validation and correlation. Validation is 
assuring that the analysis program computes what 
it is supposed to compute (as defined by the 
equations and method of solution). Correlation is 
comparison of the analysis results with the 
"real-world". Validation and correlation require 
substantial effort for a large sophistocated analysis 
to exercise multiple-option combinations for multiple 
configurations. Utilization of prior effort is 
possible by direct comparison of restructured 
modular input and output with the same quantities 
from the poorly structured analysis. The trade- 
off is the effort required to identify these inter- 
mediate values in the poorly structured analysis 
versus the effort saved in validation and correla- 
tion. This potential savings is one of the most 
significant benefits of the restructuring approach. 

Utilization of Information in existing documentation 
provides another potential reduction of effort for 
the restructuring approach. Since restructuring 
utilizes the approach and derivation of the current 
analysis, the documentation pertaining to theoretical 
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development is still valid and may be utilized in 
generation of new documentation. In addition, use 
of an existing method allows the development team 
to concentrate on the program structure. Thus, 
restructuring is favored if the current analysis 
approach is relatively well documented. 

Another major benefit of restructuring is potential 
implementation of improvements in the near-term. 
Incorporation of at least partially restructured 
modules into the original program prior to comple- 
tion of restructuring is possible. Small changes 
are simpler once a restructured module goes into 
production. Errors in the existing analysis may 
be uncovered and corrected, and new capabilities 
may be implemented in the restructured modules 
prior to completion of restructuring the whole 
program. Any benefits which may be incorporated 
into the new module are thus ootential near-term 
benefits as well. 

Determination of the suitability of a currently 
available analysis for restructuring requires an 
examination of its structure. (All programs have 
structure, though some have very bad structure 
in terms of maintainability and modifiability). The 
current analysis structure must be compared to a 
desired analysis structure, which of course, 
requires at least a first-cut design of a "good* 1 
structure. The goal of the comparison is a map- 
ping of functions, and the connections between 
functions, from the poor structure to a good 
structure. The mapping is not likely to provide a 
one-to-one correspondence, but will provide an 
indication of the effort needed and trade-offs 
required for restructuring to be successful. 

A functional mapping exercise indicates that 060 
is a good '‘target" analysis for restructuring. A 
first-cut design of "good" structure and a first- 
cut mapping of components from poorly structured 
C-60 to "well" structured modules has been per- 
formed. The first-cut design of "good" structure 
with clearly defined functions is shown in Figure 
3. The mapping of corresponding functions in the 
current C-60 is illustrated by Figure 4 as a struc- 
ture chart with functions distributed throughout 
♦he analysis. While the structure of current C-60 
is clearly in need of reorganization, the mapping 
exercise indicated that validation, correlation, and 
near-term improvement benefits of restructuring 
should exceed the cost of efforts to identify, 
isolate, remove, replace, and reconnect pieces of 
analysis. In addition, the existence of relatively 
complete and well-written documentation makes 
program C-60 a good candidate for restructuring. 

The Restructuring Process 

The first task in the restructuring process is 
development of a plan. A general outline of the 
plan .'or restructuring program C-60 is provided as 
Table 6. The initial tasks define desired attri- 
butes for overall program stri cture, data struc- 
ture, and control tructure, and provide reding 
guidelines and documentation standards. se 
tasks lay the groundwork which is esse.itioi to the 
restructuring design process, and thus merit long 
and serious consideration. However, flexibility to 


allow and in fact plan for review and revision of 
initial structural att^Lutes, coding guidelines, and 
documentation standards is advisable to provide a 
better final result. Initial testing (by example or 
trial) of guidelines, particularly documentation and 
coding guidelines, may provide answers to critical 
questions such as 'Are the restrictions realistic?, 
Will they be complied with over a long program 
life-cycle by a variety of programmers/analysts/ 
users?. Will the documentation be maintained? Is 
it too cumbersome, or incomplete?, Will this struc- 
ture still work if we add more coupling considera- 
tions?' Though not explicit in the plan outline, 
flexibility for refinement of guidelines is assumed. 

A first-cut "S^rawman" design of the overall 
program structure begins the actual design pro- 
cess. (This step was actually performed, as was 
required, in the mapping exercise which illustrated 
suitability of C-60 for restructuring. See Figure 
3). A first-cut design of the Main Control Execu- 
tive is obtained by viewing the analysis as con- 
sisting of only its top level "global" functions 
(e.g.: Velocity, Airloads, Trim, Response). The 
main design loop may then be executed on a func- 
tion by function basis unt'l all global functional 
modules have beer, designed, built, tested, and 
documented. The restructur ing process is com- 
pleted by final refinement of the Main Control 
Executive design, system integration testing, and 
completion of system documentation. Major stages 
of the restructuring process as outlined above are 
desr-ibed in more detail in the paragraphs which 
follow. 

Design principles were selected to olace the de- 
sired emphasis on high priority criteria. To 
improve maintainability and modifiability, design 
principles are selected which minimize the human 
effort required to identify and correct program 
errors, and to define and implement changes to 
program requirements. Ycurdon and Constantine 6 
define desirable characteristics of the narts of a 
system for maintainability and modifiability: 

" the cost of maintenance is minimized 

when parts of the system arj: 

- easily related to the application 

- manageably small 

- correctable separately ' 

" the cost of modification uf a system will 

be minimized when its parts are: 

- easily related to the problem 

- modifiably separately." 


The design procedure should provide partitioning 
or organization of the analysis into pieces which 
are manageably small (for human comprehension), 
clearly defined, well documented, and which reflect 
the "real-world" partitioning of the problem. 
Similarly, these pieces should be connected to one 
another in ways which are clearly defined, well 
documented, and which reflect only "real-world" 
relationships without extraneous links. Design 
principles utilized in the present effort to build 
such a program structure are functional decompo- 
sition, hierachal control structure, and data trace- 
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ability. These principles, which are described 
individually in the following paragraphs, are used 
to promote simplicity and clarity in the way the 
program models the solution it represents. 

Functional decomposition is a top-down approach 
composed of repeated subdivisions from "big pic- 
ture" functions to code level functions. It is the 
judicious partitioning of a problem into cohesive 
decoupled units or modules. (Detailed discussions 
of intermodular cohesion and intramodular coupling 
are presented in References 2 and 6). The tricki- 
est aspect of this concept is determining 'func- 
tional decomposition with respect to what?'. "The 
choice of what to decompose with respect to has a 
major effect on the goodness of the resulting 
program and is therefore the subject of much 
controversy . " 2 If the definition of functions is 
derived from a data flow diagram the result is data 
flow design. If the design is built on the basis of 
data structure it is data structure design. 
Bergland 2 describes data flow design (pseudonyms: 
transform centered design or composite design), in 
its simplist form as "nothing more than functional 
decomposition with respect to data flow. Each 
block is obtained by successive application of the 
engineering definition of a black box that trans- 
forms an input data stream into an output data 
stream". Another analogy is an engineering 
system block diagram with transfer function rela- 
tionships between input and output for each block. 
The art or magic of functional decomposition is in 
definition of a model of the real world as func- 
tions. 

It is in regard to tin. task, of judiciously break- 
ing an analysis into functions that model the 
"real-wor'd", that the ro!« of engineer/analyst and 
the role of programmer/anaiyst have a critical 
interface. Careful partitioning may reflect not 
only the "state-of-the-art", but also the areas of 
anticipated expansion of capability. Careful func- 
tional partitioning should take care to explicitly 
represent all functions, including simple approxi- 
mations of functions. This is necessary if the 
program structure is to accurately represent the 
structure of the "real-world" problem, and be 
easily identified and modi c ied to improve the ana- 
lytical model. The importance of good functional 
decomposition makes the ergineer/analyst a criti- 
cal, though often unused link in the software 
development/maintance/modif ication chain . 

Hierachal control structure attempts to define clear 
traceable lines of decision-making power. This is 
accomplished by requiring that decisions be made 
only once, and by placing decisions immediately 
above the highest level module effected by the 
decision, thereby limiting authority of all lower 
level functions. The result may be likened to a 
human organization, in whr.h "decision-making" 
power is graduated from tof. -level executives to 
mid-level managers to level "number 

crunchers", as shown in Figure 5. A similar 
concept is defined by the term "decision-hiding" 4 , 
in which decision information is accessible on a 
"need- to-know" basis. Hierarchal control struc- 
ture tends to minimize extraneous control or deci- 
sion connections, eliminate control redundancy, 


and guarantee consistency of all option selections. 
Involvement of engineering personnel in definition 
of the Control Hierarchy will provide additional 
insight into anticipated future analytical options 
and/or vehicle configuration. 

Data traceability is the characteristic of having 
clearly defined single-source paths of data flow. 
This characteristic is desirable for maintainability 
and modifiability because it eliminates redundant 
and/or inconsistent variable definitions. This 
characteristic also tends to minimize extraneous 
connections by eliminating unnecessary and/or 
misplaced calculation of variables. The debate 
over transfer of information by argument list 
versus transfer by common "global" data Is an 
example of an issue of data traceability. Argument 
list transfers can become cumbersome and may 
consume extra pregram execution time, but gener- 
ally provide better data traceability. This issue is 
addressed specifically in definition of coding 
guidelines. 

The third step in the restructuring process (out- 
lined in Table 6) is the definition of a data struc- 
ture. This refers to the organization of data flow 
from input parameters to output data. It consists 
of the division of program input data, variable 
parameters, and output data into categores and 
subcategories which reflect "real-world" defini- 
tions. Data structure is reflected in the organi- 
zation of documentation, particularly "data 
dictionaries" which provide symbolic nomenclature, 
physical definition, units, sign convention, and 
FORTRAN name. The categories used for restruc- 
turing C-60 input data are trim, structural prop- 
erties, aerodynamics, geometry, downwash para- 
meters, and controls. (Program control pa-ameters 
are treated with a parallel structure (e.g.: trim 

controls, input controls, etc.) under the topic of 
Control Structure). Parameters which are com- 
puted as functions of only input data, and which 
could, in fact, be treated as input data in that 
they remain fixed throughout the analysis are 
grouped with input data to form "extended data". 
Examples of additional parameters included in 
"extended data" are lumped physical properties 
derived from distributed physics) property curves. 

Organization of variable parameters (i.e.: parame- 

ters which change in value during the analysis) is 
based on functional decomposition. Variables are 
first defined either as "global" results of a speci- 
fied function (e.g.: the results of the "response 

module" are deflections, slopes, loads, etc.) or as 
local internal values appearing only in subordinates 
of the specified function (e.g.: transfer matrix 

elements, unsteady stall time delay, etc). The 
resulting categories of variables thus reflect the 
top-level global functions. Refinement to re- 
peatedly lower level functions provides similar 
organization of local var'ables tu parallel dati f low 
through the analysis. 

Output data structure duplicates the structure of 
variable parameters, illustrating the concept that 
any resulting variable quantity may be considered 
an output. Highest level function output, or 
global output is collected for summary information. 
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The "output" function is otherwise distributed 
throughout the analysis by activation or “calling" 
of output utility routines or subfunctions. This 
treatment provides standardization of formats, 
simplified revision of standard formats, and simpli- 
fied identification, tracing, addition or deletion of 
output parameters. 

Definition of control structure refers to the organ - 
17 ition of "decision-making" parameters or program 
controls. The organization of control parameters 
reflects the levels of decision-making defined by 
the control hierarchy as well as the functional 
breakup defined by functional decomposition. 
Controls are "decomposed" first by global function 
classifications: Input, Velocity, Airloads, Trim, 

Response, and Output. Successive subdivision 
from high-level decision-making to low-level 
decision-making is performed on a "need-to-know" 
basis to minimize coupling of program controls. 

Coding guidelines are defined as the next step in 
the restructuring ^.ocess to provide standardiza- 
tion, to improve clarity, to enforce data trace- 
ability requirements, and to maintain data and 
control structures. Standardization is needed to 
provide consistency across a variety of pro- 
grammers/analysts/engineers with a corresponding 
variety of programming styles, nomenclature ore f - 
erences, etc. The attributes of this standard will 
have a significant impact on future maintenance 
and modification costs. The most tempting trade- 
off in coding practices is short-term expediency at 
the expense of long-term clarity. The provisions 
made in coding guidelines may deter such prac- 
tices. Standards of particular interest from the 
perspective of maintainability and modifiability are 
those which influence data traceability. These 
standards are any rules or guidelines which pro- 
mote the identification and understanding of a 
source of information. Some examples of stanaards 
which promote data traceabilit/ are prohibition or 
restricted use of "EQUIVALENCE" statements, 
FORTRAN variable naming conventions which 
reflect the meaning and source of the data and 
restricted use of FORTRAN COMMON blocks for 
variable data storage. 

Usage of common block data storage is a particu- 
larly controversial issue because the trade-off of 
benefits is significant. Two main drawbacks of 
COMMON block usage are the difficulty in tracing 
the origin of values, and the danger of inadver- 
tent and undetected redefinition or "over-writing" 
of data. A major benefit of COMMON block usage 
is the ease and simplicity of multi-point access to 
information. Common blocks of Information may 
best be utilized as single-source, multi-destination 
vehicles of Information transfer and storage to 
achieve major benefits and avoid main drawbacks of 
usage, as illustrated by Figure 6. 

Definition of documentation standards is one of the 
most difficult and time-consuming tasks of the 
restructuring process. Repeated review/revision 
iterations involving personnel with different per- 
spectives are essential to dcinltion of useful 
documentation. Insights from perspectives of 
programming, analytical development, and pro- 


duction usage are essential. Documentation must 
provide enough information to provide needed 
understanding without providing so much informa- 
tion that needed information is obscured, In 
addition, the information must be structured so as 
to be easily modified and quickly retrieved and to 
prevent conflicting or redundant information. 

First-cut designs of overall structure and the Main 
Control Executive reflect the interaction of global 
functions. Refinement of the design is achieved 
by iterative functional decomposition based pri- 
marily on data flow. The top-level second-cut 
design is shown in Figure 7. An essential element 
of the design iteration is that it involves in- 
dividuals representing computer technology, the 
engineering developer, and the user community. 
The main design loop is then activated to design, 
build, test and document functions on a module by 
module basis. A second-cut deta'i design of the 
Input function is shown in Figure 8. 

For each module, requirements rm.st be defined in 
the form of a first-cut modu e specification or 
"module spec" including ? first cut detail 
"strawman" design. Discussion of a design is 
much more fruitful when based on a strawman. It 
helps to point out the more subtle and obscure 
requirements and restrictions. It is also useful in 
establishing, illustrating, and clarifying special 
nomenclature . However, too large an effort should 
not be expended in putting together the 
"strawman" spec, or natural reluctance to "waste" 
effort may compromise the design effort by dis- 
couraging changes to the strawman. The iterative 
design-change/review process, starting with the 
strawman design is performed until a satisfactory 
detail design results. 

Steps of module-building, validation, and documen- 
tation may begin upon completion of the module 
design. A mapping of the module function to the 
current analysis code is required to identify code 
connections for validation. There generally will 
not be a one-to-one mapping of new module code 
and original analysis code. The original analysis 
will contain duplicate code (possibly inconsistent 
near-duplicate sections), have some functions 
unrecoverably distributed (in practical terns), and 
have some functions which do not exist as junc- 
tions at all. Coding guidelines define standards 
for the module-building process, including specifi- 
cation of the format for in-line documentation 
which should be included as comment statements in 
the code of the new module. The module is then 
tested by comparison with the current analysis 
intermediate and final calculation output. This can 
be achieved by adding namelist or write statements 
as temporary mod’fications to the original program. 
(The required variables from the original analysis 
were identified in the mapping step above). 
Documentation of the global module, including 
global function executive «r.d all subordinate 
functions is then finalized. 

The Main Control Executive design is finalized after 
completion of design of all global functions. This 
is necessary because design revisions of even 
global level functions may occur during the Itera- 







V r 


tive design loop process. Testing of the main 
control executive is performed by exercising all 
combinations of global level control options with 
'dummy" global functions. Redacement of "dum- 
my" functions with completed functional modules 
constitutes system integration, which is followed 
by integration testing, completion of system docu- 
mentation, and finally, incremental release of the 
restructured program for production use. 

Current Status 

We are in ihe process of executing this restructur- 
ing plan for program C-60, and are presently in 
the global function design loop. Restructured 
functions which have been implemented in the 
production program are Downwash (subordinate of 
Velocity), Coupled Flap-Pitch Response (subordi- 
nate of Response), Aerodynamic Coefficient Deter- 
mination (bottom level subordinate of Airloads), 
and various standard utilities of Input and Output. 
Some general observations we have made during 
this activity are (1) that no design is ever final 
and therefore flexibility must be built in, (2) 
review with other interested parties improves the 
resulting design, (3) definition of documentation 
standards is at least as difficult as the actual 
design process, and (4) the potential near-term 
benefits from implementation of restructured mod- 
ules into production are extraordinary. A discus- 
sion of these points is given below. 

The program design structure, even at the top 
global-function level, evolves during the design 
process, and beyond. Top-level functions of the 
current design, as shown in Figure 7, contrast 
the original design which was shown in Figure 3. 
Additional functions, such as nonlinear forcing, 
summary report, graphics, and rotor-airframe 
coupling, were added as a result of multi-person 
review, anticipation of future needs and insights 
from ongoing design refinement. Further revision 
is anticipated. 

Documentation standards evolve in the design 
process, similar to the actual program structure 
evolution. Initial elements listed in Table 7 were 
revised to a scheme employing three documents 
with items listed ; n Table 8. The division, though 
still in work, is similar to that suggested by Kerr, 
Potthast, and Anderson’; model formulation, 
user's manual, and programming manual. This 
resulted from trial generation and revision of 
documentation, which proved to be too cumbersome 
in its original form. Again, multi-person review 
provided major insights. Documentation completed 
thus far, including the input data dictionary and 
input structure definition, has beer, very useful 
in reducing user errors in input preparation. 

Restructuring a i improve efficiency as a side- 
effect. Restructuring of the Aerodynamic Coeffi- 
cient Determination function, a bottom level sub- 
ordinate of Airloads, revealed inefficient loop 
structure resulting in unnecessary recalcu'ation of 
values. Restructuring of the function Lo improve 
clarity, maintainability and modifiability also pro- 
vided more efficient operation. The end result of 
implementing the restructured function in the 


production program was reduction of total CPU 
execution time by 17 percent for a typical 
case. 

Previously undetected program errors may be 
uncovered in the process of validating restruc- 
tured modules. During the validation process, 

differences in answers provided by the restruc- 
tured module and the original program were found. 
Usually, this was the result of a coding error in 
the new module, which illustrates the primary 
purpose of the validation effort. However, some- 
times it was found that the original program was 
incorrect. Most of the time these corrections were 
not significant, but in at least one instance, the 
error correction significantly improved correla- 
tion. In the past, the vibratory hub lead 
calculations sometimes depended upon the accuracy 
of the initial trim guess. After an error was 
uncovered in the wake update routine, the depen- 
dence of the hub loads on initial trim 

was dramatically reduced. In addition, the correl- 
ation with measured pressure data was sub- 

stantially improved, as shown in Figure 9. 

Another restructuring benefit is that it has been 
significantly easier to incorporate new analytical 
capability. A number of improvements have been 
added, including the addition of a nonlinear 
multi-load path flex-beam capability, even though 
the Response function was only partially 
structured. Having a data map, control flow and 
partial restructuring really reduced the effort 

required. A number of similar improvements were 
attempted in the late 70's, but they had to be 

abandoned since the change could not be checked 
out with a reasonable effort. Restructuring of 
the Response function made a similar contribution 
to revisions to add nonlinear pendulum flap ab- 
sorbers and consolidate calculations for load 
and frequency prediction capabilities. 

Output capabilities have been expanded and made 
more user-friendly. Restructuring has facilitated 
development of flexible, centralized output modules 
from which the user can select any of 152 output 
record names representing different output arrays 
(each array is converted into one of three stan- 
dard formats). Each of these arrays can be either 
not output or output to paper, microfiche, on-line 
printer plots and/or tape. The tape can then be 
automatically transformed into the required form 
for a number of display devices (both video and 
hard copy plots). In addition, all output is 
completely labeled with a description, units and 
sign convention. 

Reorganization of input data and input processing 
has reduced input errors and the time required for 
user preparation of input data. This was accom- 
plished by development of centralized input mod- 
ules with options for using standard data files 
established for each aircraft and the ability to 
input either distributed or lumped physical proper- 
ties. Scaling factors are provided for each of the 
physical property characteristics. Finally, the 
input data is printed out in both standard loader 
format and logically grouped, annotated and for- 
matted arrays, with description, units and sign 
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convention to allow the user to easily check the 
input. 

Restructuring aids development of interdisciplinary 
analysis by simplifying the incorporation of 
analysis components from other technical areas. 
This capability was demonstrated while performing 
the restructuring of the Downwash function in the 
C-60 program. The restructuring of C-60's non- 
uniform downwash function resulted in the de- 
finition o * the functional data connections so that 
any 'generic 1 downwash function (that used air- 
load s and geometry as inputs and provided velocity 
distribution as output) could be used. Next, a 
non-uniform downwash analysis from the L-02 
program was restructured and then transplanted 
into C-60. Currently a third downwash analysis 
(from the B-65 performance program) is in the 
process of restructuring for inclusion in C-60 by 
year's end. It should be noted that this tech- 
nology interchange works both ways. Since the 
C-60, B-65 and L-02 wake functions were re- 

structured to the same criteria, these interface 
boundaries are defined identically. Therefore, it 
is possible for both B-65 and L-02 to use the C-60 
downwash function and each others' as well. The 
value of this exercise is to show that it is reason- 
able to transfer technology from discipline to 
discipline and to demonstrate the value of good 
(and consistent) program structure in aiding the 
transfer. Other technologies planned for near- 
terrr; cross fertilization include unsteady aero- 
dynamics, free flight aircraft trim, and dynamic 
flight controls. 

Another benefit of this technology interchange is 
that the three restructured Downwash functions in 
C-60 v'ill allow the ability to evaluate different 
analytical emulations for the same function. 
Different analytical models of such concepts as 
shed wake, vortex sheet, roll up, lift/wake com- 
patibility and wake convergence, etc. can be 
investigated with identical external fo. mulations, (a 
physical impossibility when these routines were 
located in different programs). Using similar 
strategy, functional structuring also allows multiple 
levels of complexity for a single function. For 
example, C-60 currently has three levels of com- 
plexity for blade pendulum absorbers: -n ideal- 

ized absorber (useable for preliminary design), a 
linear absorber (with couplings and offsets), and a 
full non-linear absorber (with large angles). 

As discussed above, our experience to date shows 
that restructuring works, and provides extensive 
near-term benefits with production implementation. 
It has been possible to develop a hybrid program, 
partially structured and partially unstructured, 
that can be utilized as a production analysis in 
parallel with its restructuring, Of course, after 
each significant restructuring effort, a new pro- 
duction module is developed, which has the same 
or improved capability of the previous version. 
(A modification index Is kept in the front of the 
output to summarize each change, as shown in 
Figure 10). When substantial differences In the 
calculated results between versions occur, correla 
tion is performed to show that the new version Is 
at least as good as the original version, if this 


level of correlation cannot be reached, the old 
version is not replaced. 

Conclusion 

Experience in the effort to restructure C-60 indica- 
tes that restructuring a "mature" analysis is a 
viable and worthwhile remedy for the maintenance 
and modification problems of a current poorly 
structured rotorcraft analysis. The success and 
productivity of the restructuring effort in terms of 
capability-gained for effort-expended depends to a 
large degree on the organization and documentation 
of the current poorly structured analysis. Many 
near-term benefits are possible from incorporation 
cf restructured functional modules into the pro- 
duction program. Near-term benefits achieved 
thus far for program C-60 are listed below. 

- Reduction of program errors 

- Reduction of user errors (input and output) 

- Reduced run-time 

- Simplified incorporation of new capabilities 

- Enhanced technology transfer 

- Improved correlation 

In addition, some important lessons were learned 
concerning the procedure or process of re- 
structuring, and are outlined below. 

- No design is ever final, and therefore 
flexibility must be built in. 

- Reviews of design and documentation stan- 
dards by representatives of programming, 
computer technology, analytical develop- 
ment, and user communities provide sur- 
prising insights *nd better "final" results. 

- The definition of standards for documenta- 
tion is at least as difficult and as important 
as the actual design process. 
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Table 1. 

SOPHISTIC MED COMPUTER TOOLS 

- GRAPHICAL DISPLAY PACKAGES 

- OPERATING SYSTEMS 

- COMPILERS 

- DEBUGGMQ AIDS 

“ DATABASE MANAGEMENT SYSTEMS 

- PLOW DIAGRAM UTILITIES 

- CHART GENERATION PACKAGES 

- WORD PROCESSORS 


Table 

3. 

SOFTWARE ATTRIBUTES AS DESIGN CRITERIA 

- CLARITY 

- GENERALITY 

- COHESION 

-INDEPENDENCE 

- COMPLEXITY 

- MAINTAINABILITY 

- CONNECTIVITY 

- MODIFIABILITY 

- CONSISTENCY 

- MODULARITY 

- CONTINUITY 

- PORTABILITY 

- CORRECTNESS 

- RELIABILITY 

- CORRESPONDENCE 

- REU8EA"!t 

- COUPLING 

- ROLE ADAPTABI' 

- EFFICIENCY 

- TESTABILITY 

- EXTENDIBILITY 

- TRANSPARENCY 

-FLEXIBILITY 

- UTILITY 


Table 2. 

INDIVIDUAL PREFERENCES IN PROGRAM DEVELOPMENT 

- NOMENCLATURE 

- FORMAT 

- VARIABLE NAME8 

- UNITS/NONDIMENSIONALITY 

- 8IQN CONVENTIONS 

- IN-CODE COMMENTS 

- ARGUMENT OR COMMON TRANSFERS 

- IMPLIED OR EXPLICIT LOOPS 

- EXPLICIT OR VARIABLE DIMENSIONS 

- INTEGER OR REAL PROGRAM CONTROLS 

- VARIABLE PRECISION 


Table 4. 

SOFTWARE DESIGN PRINCIPLES AND TECHNIQUES 

- ABSTRACTION 

- BOTTOM-UP DE8IQN 

- COMPOSITE DESIGN 

- DATA ENCAPSULATION 

- DATA FLOW DESIGN 

— DATA STRUCTURE DESIGN 

- DATA TRACEABILITY 

- DECISION HIDING 
-FUNCTIONAL DECOMPOSITION 
-HIERARCHY 

- HIERARCHAL CONTROL 

- HYBRID (TCP-DOWN/ BOTTOM-UP) DESIGN 

- INFORMATION HIDING 

- PARTITIONING BY OBJECTIVE 

- PROGRAMMING CALCULUS 

- SYEPWI8E REFINEMENT 

- TOP-DOWN DESIGN 

- TRANSFORM-CENTERED DE8IGN 
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Table r. 


Table 5. 


DESIGN CRITERIA DEFINITIONS 


OVERALL COMPUTATIONAL 
EFFICIENCY 


GENERALITY 


MAINTAINABILITY 


MODIFIABILITY 


RELIABILITY 


BROADNESS. SCOPE, OR 
ABSTRACTNESS OF TASK 
DEFINITION 

EASE OF DETECTION AND 
CORRECTION OF PROGRAM 
ERRORS 

EASE OF ACCOMMODATING 
NEW REQUIREMENTS 


CONSISTENCY AND REPEATABILITY 
OF CORRECT PERFORMANCE 


EASE OF USE OR 
USER-FRIENDLINESS 


ORIGINAL DOCUMENTATION REQUIREMENTS 

MODULE SPEC (FOR EACH SUBROUTINE) 

I. SUMMARY SHEET 

{FUNCTION NAME AN) DESCRIPTION. SUBORDINATES 
AND St/PERORONATFa, WPUT AND OUTPUT PARAMETERS) 

II. LOCAL MODULE MAP (DIAGRAM) 

(SHOW* SUBORON ATE'S, SUPERORDMATE3. 

AROUMENT UST I/O. COMMON I/O) 

III. MODULE STRUCTURE DIAGRAM 

(SHOWS INTKANAL STRUCTURE SUS FUNCTIONS) 

(V. SEQUENCE FLOW DIAGRAM 
(CLASSICAL FLOW CHART) 

V. CONTROL DECISIONS 

(PRESENTS OPTIONS AND TESTS MADE ON CONTROL 

parameters) 


VII. DERIVATION OF EQUATIONS 

VIII. FORTRAN VARIABLES 

(FORTRAN NAMES. SYMSOLIC RFFERENCES, 

AND DEFWITION8) 

IX. CODE (WITH COMMENTS) 

(LISTING OF ACTUAL FORTRAN CODE WITH IN-LINE 
COMMENTS) 

X, additional notes 

(ANY ADDITIONAL COMMENTS, A SUCH AS NOTWd 
EXCEPTIONS TO COOMd GUIDELINES, ASSUMPTIONS 
OR AWTICPATION OP FUTURE REVISIONS) 

DATA DICTIONARIES - INPUT, VARIABLE#, OUTPUT 

- ALPHABETIZED AND CROSS-REFERENCED 

- PROVIDE SYMBOLIC NOMENCLATURE. PHYSICAL 
DEFINITION. UNITS, SIGN CONVENTION, FORTRAN 
N '.ME, ANO DERIVATION REFERENCE 


Table 6. 


PLAN rOR RESTRUCTURING C-60 


Table 8. 

REVISED (2nd CUT) 
DOCUMENTATION REQUIREMENTS 


1. PRIORITIZE DESIGN CRITERIA 

- MAINTAINABILITY 

• MODIFIABILITY 

2 . DEFINE DE8IGN PRINCIPLE# 

- FUNCTIONAL DECOMPOSITION 

- HIERARCHAL CONTROL 

• DATA TRACEABILITY 

5. DEFINE DATA STRUCTURE 

4. DEFINE CONTROL STRUCTURE 

6. DEFINE COOING GUIDELINES 

5. DEFINE DOCUMENTATION STANDARD I 

7. DESIGN Is* 5UT OVERALL 8TRUCTUHE CSTRAWMAN’) 

8. DESIGN m-CUT MAIN CONTROL EXECUTIVE 
S. GLOBAL FUNCTION DESIGN LOOP 

- D( JIGN/REVnW ITERATION 

- BUILD MODULE 

- TCST MOOULS 

- COMPLETE MODULE DOCUMENTATION 

• (NEXT GLOBAL FUNCTION) 

10. COMPLETE MAIN CONTROL EXECUTIVE 

11. SYSTEM INTEGRATION TEBTINQ 

IE. COMPLETE SYSTEM DOCUMENTATION 


DERIVATION DOCUMENT 

- CONTINUOUS/SEMI-CONTINUOUS DERIVATION 
(NOT BROKEN WTO SUBROUTINES) 

- CROSS-REFERENCED TO SUBROUTINES, INPUT 
DATA, OUTPUT DATA, AND FORTRAN VARIABLES 

PROGRAMMING MANUAL 

- MODULE SPEC * 

I. SUMMARY SMIIY 
n. LOCAL MOOULS MAP 
<11. MOOULS * THU C TUP f DIAGRAM 
f/. SIQUINCI FLOW DIAGRAM 
V. CONTROL DtCItlON* 

VL FORTRAN VARIABLE* (WAS VM> 

VI CODS WfTH COMMBNT* (WAS IX) 

VIM. ADDITIONAL NOTIS (WAS X) 

- RIQARDMQ COPS 

- DATA DICTIONARY - VARIABLES 
USER’S MANUAL 

- MODULE SPEC * 

L SUMMARY SHUT 
N. SQUATIONS (WAS VI) 

III aoqitiqnal NOTIS (WAS x) 

- RIOAROWO SQUATIONS 

- DATA DICTION ARlES-INPUT AND OUTPUT 
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Figure t. 

LAW or C ON T!»:U‘!Na CHANGE : 

k SV^TEM THAT 19 USED UNDERGOES CONTINUING 
CHANGE UNTIL IT IS JUDGED MORE COST-EFFECTIVE 
TO FR'EZE AND RECREATE IT. 

LAW OF INCREASING UNSTRUCTUREDNESS: 

THE ENTROPY (DISORDER) OF A SYSTEM INCREASES 
WITH TIME UNLESS SPECIFIC WORK 18 EXECUTE^ J 
MAINTAIN OR REDUCE IT. 
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Figure 9. 

IMPROVED VIBRATORY AIRLOAD CORRELATION 
USING RESTRUCTURED C-60 DOWNWASH ,IODEL 



OLoc-eo 


NEWC^O 


























DISCUSSION 
Paper No. 12 


RESTRUCTURING THE ROTOR ANALYSIS PROGRAM C-60 
P. G. Phelan 
and 

F. J. Tarzanin, Jr. 


Wayne Mantay, U.i. Army Structures Laboratory : I have two questions that I think are related, I 

hope you do too. When you restructured you said you uncovered at least one major problem. Was 
it in fact that error in the downwash, was that the one? 

Phelan : That showed one of them, yes. Part of the improved correlation was that. That wasn't 

the total improvement in correlation: we also had improved capability. 

Mantay : No, I understand about the correlation, but the error that you uncovered in C-60, was 

that the major error you alluded [to]? 

Phelan : Yes. 

Mantay : That was in the downwash? 

Phelan : Yes, that was in the downwash. 

Mantay : I didn't pick it up on your slide for that correlation, but was that the high speed 

case from Euan Hooper's data base that he had trouble with; was that the problem child that you 

set straight? 

Phelan : Yes, 

Marty Schroeder, Solar Energy Institute : Your presentation was [very good] and I think the work 

in structured programming is sorely needed. I'm not familiar with C-60 though. What language 
is it written in? 

Phelan : FORTRAN. 

Shroeder : Have you considered looking at other languages like PASCAL or C for a structured 

program? 

Phelan : We are working on restructuring an existing analysis for a lot of reasons that I didn't 

really get into, but are in the paper. We haven't looked at also changing languages, but yt ^ 
could do that. We haven't looked at doing that. 

Wendell Stephens, U.S. Army Aeromechanics Laboratory : I wanted to thank you for your paper, 

also. I have noticed that your paper, the one previous to it by Bob Sopher, a related paper 
[on] DYSCO involving Kaman, [and] perhaps, even the paper by Gangwani at Hughes when he spoke 
about a new program all have tended to go th:s direction which I applaud. My specific question 
to you is when you begin restructuring this program have you come across any executive-type 
utilities that you have had to build in FORTRAN that have helped your ability to transfer data 
from module to module. It sort of relates to the previous question , ick here of perhaps going 
to a different language for certain structures for your executive functions. I was wondering if 
you found that you had to develop any utilities for data transfers? 

Phelan : We haven't yet, but I think part of that is maybe thav our final main control executive 

design is . . . the first cut comes at the beginning of the process--the last final design comes 
at the end after you have decided and really finalized what your global top level functions 
are. So we've discussed different ways to implement a main control executive quite a bit, but 
we have not implemented it as of yet. So, we will see. 

Ed Austin, U.S. Army Applied Technology .aboratory : I think it's very interesting the approach 

you have taken to conceive of restructuring an entire program and then to work from kind of the 
bottom up. Do you have any speculations about what will happen on that day when suddenly the 
master program is the only thing left to change ano yon have all these pieces and you haven't 
designed apparently the final master program? It doesn't sound to me lik- you have anyway. 

Phelan : You mean the main' control as .'ar as the . . . 

mus, in : I saw this incredible diagram of the program the way it wa* you starW »nd 

wires go every which way. I saw your final version which is a sample wiring diagra I 
guess I don't see how you plan to go from this complicated set down wo Just a few wires. It's 
kind cf like the cime ray wife decided to rewire our car and she took uil c he wires off the 
distributor at the same time. 
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Phelan: I dort see it as a big problem because the reason why the design is ... we have done 

a lot of work on laying out a first cut executive, but the problem is you cannot implement the 
executive in a piecemeal way because that defines . . . on? of the very last things is how you 
are going to make these common blocks all well structured. Well, when you start out with one 
that is connected everywhere, you can’t do that first; you have to wait until you have consoli- 
dated things. I can’t take the connections from airloads that go everywhere and eliminate the 
connections until I've brought all the pieces together and once they are in one piece then you 
have identified your single source. Do you see what I mean? Do you have a better explanation? 

Frank Tarzanin : We have done some partial module restructuring and then we have done, actually 

completing the downwash moJule restructuring and or ce you connect those wires you c*su. isolate 
the downwash as a kind of structured subprogram. We’re going to slowly build structured sub- 
programs then build the total program on top. In fact we are learning and v.hat we started to dc 
was take one thing in airloaos, in fact that routine tnat saved a lot of time was an experiment. 
Can we grab a routine out of the middle of this mess and restructure it and put ic back in and 
i ave it work. And it diu. You’ve got to find the connections, and define the interface. 

Phelan : I think that another thing that is important too is when you do that the connections 

are reduced Because what started out as a ball with a whole bunch of strings attached--you can 
eliminate the strings. You have identified a single source that can go everywhere as you con- 
solidate all through; they kind of connect. 

Tarzanln : Each step makes it simpler. 
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